Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-pem-mime-00.txt < prev next >

Wrap

Text File | 1993-03-03 | 16.3 KB | 706 lines

draft MIME-PEM Interaction Nov 92 MIME-PEM Interaction Mon Nov 16 15:51:54 1992 Steve Crocker Trusted Information Systems crocker@tis.com Ned Freed Innosoft International, Inc. ned@innosoft.com Marshall T. Rose Dover Beach Consulting, Inc. mrose@dbc.mtview.ca.us 1. Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as a "work in progress". 2. Abstract This memo defines a framework for interaction between MIME and PEM services. Expires May 16, 1993 [Page 1] draft MIME-PEM Interaction Nov 92 3. Introduction In the Internet community, an electronic mail message has two parts: the headers and the body. The headers form a collection of field/value pairs structured according to RFC 822 [1], whilst the body, if structured, is defined according to Multipurpose Internet Mail Extensions (MIME) [2]. Privacy Enhanced Mail (PEM) [3-6] allows encryption and authentication services to be applied to an electronic mail message. This memo defines a framework whereby the services provided by MIME and PEM are used in a complementary fashion. In order to provide for MIME-PEM interaction, two content types, "multipart/pem" and "application/pem", are defined. Then, the relationship between MIME and PEM is described in terms of two functions: message composition and message delivery. Expires May 16, 1993 [Page 2] draft MIME-PEM Interaction Nov 92 4. Definiton of new Content Types 4.1. Definition of the multipart/pem Content Type (1) MIME type name: multipart (2) MIME subtype name: pem (3) Required parameters: boundary, privacy (4) Optional parameters: none (5) Encoding considerations: always 7bit (6) Security Considerations: see [3] This subtype of multipart always contains two body parts: the first is an arbitrary content; and, the second is an application/pem content which describes the privacy- enhancements which resulted in the first body part. The value of the first body part corresponds to <pemtext> as defined in [3]. Note that if <pemtext> is represented using the base64 encoding, then a a Content-Transfer-Encoding: header is present which indicates use of the base64 content encoding. Otherwise, if a Content-Transfer-Encoding: header is present, it indicates use of the 7bit content encoding. The syntax and semantics of the boundary parameter is defined in [2]. The syntax of the privacy parameter, using the ABNF notation of [1], is: privacy-value ::= "ENCRYPTED" / "MIC-ONLY" / "MIC-CLEAR" with each value conveying the intent as specified in [3]. Expires May 16, 1993 [Page 3] draft MIME-PEM Interaction Nov 92 4.2. Definition of the application/pem Content Type (1) MIME type name: application (2) MIME subtype name: pem (3) Required parameters: none (4) Optional parameters: none (5) Encoding considerations: always 7bit (6) Security Considerations: see [3] The syntax of this content type corresponds to the <pemhdr> production defined in [3]. Expires May 16, 1993 [Page 4] draft MIME-PEM Interaction Nov 92 5. Message Composition When a user composes a message, it is the responsibility of the user agent to use the Content-Type: header. This allows the receiving user agent to unambiguously interpret the body and process it accordingly. This memo introduces a new header field, "Content-Privacy", which is used to indicate that the message should undergo privacy-enhancement prior to submission. The syntax of this header field corresponds to the <privacy-value> production defined above. 5.1. Pre-Submission Algorithm Prior to submission, the user agent applies this algorithm: (1) If the content does not contain the Content-Privacy: header, then the user agent sees if the content is either multipart or message. If so, it then recursively applies this algorithm to the encapsulated body parts; if not, it terminates processing for this content. (2) If the content does contain the Content-Privacy: header, the content is transformed from local form to its canonical form. Note that if a Content-Transfer- Encoding: header is present, then the content encoding is reversed as a part of this process. (3) If the canonical form of the content uses octet values outside of the NVT ASCII repertoire, and if the value of the Content-Privacy: header is MIC-CLEAR, then this inconsistency is reported to the user and the algorithm aborts. (4) Otherwise, the privacy-enhancement indicated by the Content-Privacy: header is performed, constructing a new content. The Content- headers, other than Content- Transfer-Encoding: and Content-Privacy:, are taken from the original content, if any. (5) If the value of the Content-Privacy: header is not MIC- CLEAR, then the base64 content encoding is applied and a Content-Transfer-Encoding: header is added to the new Expires May 16, 1993 [Page 5] draft MIME-PEM Interaction Nov 92 content. (6) Finally, a multipart/pem content is constructed, whcih contains the new content and a corresponding application/pem content. The multipart/pem content replaces the original content. Expires May 16, 1993 [Page 6] draft MIME-PEM Interaction Nov 92 6. Message Delivery When a user receives a message containing an multipart/pem content, the user agent may transform the content back into its original content type. This operation, the post-delivery algorithm, is performed by reversing the steps performed during the pre-submission algorithm. When the original content is reconstituted into canonical form, it may use octet values outside of the NVT ASCII repertoire. If the user agent replaces the multipart/pem content with the original content, then it must select an appropriate transfer encoding and include the appropriate Content-Transfer-Encoding: header. Upon successful completion of the post-delivery algorithm for each content, the user agent adds a new header field, "Content-Annotation", which is used to indicate the privacy- enhancements that were in effect when the content was submitted. The syntax of this header field, using the ABNF notation of [1], is: content-annotation ::= "Content-Annotation" ":" annotation-value annotation-value ::= <privacy-value> ";" <date-time> with <privacy-value> corresponding to the privacy-enhancements that was in effect during submission, and <date-time>, defined in [1], indicates the date and time that the privacy- enhancements were verified by the receiving user agent. NOTE It must be strongly emphasized that the user's level of trust in the value of the Content-Annotation: header should be no higher than the user's level of trust in the message store employed by the user agent. Expires May 16, 1993 [Page 7] draft MIME-PEM Interaction Nov 92 7. An Example For example, suppose the following message was being readied for submission: Date: Thu, 12 Nov 1992 21:43:40 -0800 From: scrocker@tis.com To: ned@innosoft.com Subject: example #1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Privacy: mic-clear Hi Ned. See how much nicer this works! After applying pre-submission algorithm, the message submitted for delivery would appear as: Date: Thu, 12 Nov 1992 21:43:40 -0800 From: scrocker@tis.com To: ned@innosoft.com Subject: example #1 MIME-Version: 1.0 Content-Type: multipart/pem; boundary="next-part"; privacy=mic-clear Content-Type: text/plain; charset=us-ascii Hi Ned. See how much nicer this works! --next-part Content-Type: application/pem Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-ID-Asymmetric: ... MIC-Info: RSA-MD5,RSA, ... --next-part-- Expires May 16, 1993 [Page 8] draft MIME-PEM Interaction Nov 92 After applying the post-delivery algorithm, the resulting message would appear as: Date: Thu, 12 Nov 1992 21:43:40 -0800 From: scrocker@tis.com To: ned@innosoft.com Subject: example #1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Annotation: mic-clear; Thu, 12 Nov 1992 22:13:40 -0800 (integrity verified) Hi Ned. See how much nicer this works! Of course, as the message being submitted was only plain text, the Content-Type: header could be ommitted. In that case, after applying the pre-submission algorithm, the message submitted for delivery would appear as: Date: Thu, 12 Nov 1992 21:43:40 -0800 From: scrocker@tis.com To: ned@innosoft.com Subject: example #1 MIME-Version: 1.0 Content-Type: multipart/pem; boundary="next-part"; privacy=mic-clear Hi Ned. See how much nicer this works! --next-part Content-Type: application/pem Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-ID-Asymmetric: ... MIC-Info: RSA-MD5,RSA, ... --next-part-- Expires May 16, 1993 [Page 9] draft MIME-PEM Interaction Nov 92 8. Observations The use of the pre-submission and post-delivery algorithms exhibit several properties: (1) It allows privacy-enhancement of an arbitrary content, not just an RFC 822 message. (2) For a multipart or message content, it allows the user to decide whether the structure of the content should receive privacy-enhancement. (3) It allows a message to contain several privacy enhanced contents, thereby removing the requirement for PEM software to be able to generate or interpret a single content which intermixes both unenhanced and enhanced components. (4) It minimizes confusion when viewing a MIC-CLEAR content without a PEM-capable user agent. (5) It minimizes confusing when viewing a MIC-ONLY content with a MIME-capable user agent that is not PEM-capable. 9. Acknowledgements David H. Crocker suggested the use of a multipart structure for MIME-PEM interaction. Expires May 16, 1993 [Page 10] draft MIME-PEM Interaction Nov 92 10. References [1] D.H. Crocker. Standard for the Format of ARPA Internet Text Messages. Request for Comments 822, (August, 1982). [2] N. Borenstein, N. Freed, Multipurpose Internet Mail Extensions. Request for Comments 1341, (June, 1992). [3] J. Linn, Privacy Enhancement for Internet Electronic Mail -- Part I: Message Encryption and Authentication Procedures. Internet-Draft, (July 23, 1992). [4] S. Kent, Privacy Enhancement for Internet Electronic Mail -- Part II: Certificate-Based Key Management. Internet-Draft, (August 6, 1992). [5] D. Balenson, Privacy Enhancement for Internet Electronic Mail -- Part III: Algorithms, Modes, and Identifiers. Internet-Draft, (September 3, 1992). [6] B. Kaliski, Privacy Enhancement for Internet Electronic Mail -- Part IV: Key Certification and Related Services Internet-Draft, (September 1, 1992). Expires May 16, 1993 [Page 11] draft MIME-PEM Interaction Nov 92 Table of Contents 1 Status of this Memo ................................... 1 2 Abstract .............................................. 1 3 Introduction .......................................... 2 4 Definiton of new Content Types ........................ 3 4.1 Definition of the multipart/pem Content Type ........ 3 4.2 Definition of the application/pem Content Type ...... 4 5 Message Composition ................................... 5 5.1 Pre-Submission Algorithm ............................ 5 6 Message Delivery ...................................... 7 7 An Example ............................................ 8 8 Observations .......................................... 10 9 Acknowledgements ...................................... 10 10 References ........................................... 11 Expires May 16, 1993 [Page 12]